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In 1984 the ITU-TSS (formerly CCITT) published standards on wide-ranging topics, includ¬ 
ing X.25 packet switching. A set of revisions to the X Series, the Blue Books, was published 
in 1989. Since that time, standards ratification and publication has been an ongoing, con¬ 
tinuous process. Each future addition or revision to the X Series standards will be made 
available, as soon as it is finalized, in individual gray booklets. Since the major building 
blocks of the X standards were completed by 1984, all post-1984 technical changes are 
relatively minor; they are discussed in this report, however. Major developments in packet 
switching center around the development of ISDN-related technologies, such as fast packet 
switching and frame relay, which provide integration of voice, video, and data, and support 
much higher throughput than traditional X.25 networks. ISDN’s relationship with traditional 
X.25 packet switching is also discussed. 


A packet switched network permits a user’s data 
terminal equipment (PC, host computer, or ter¬ 
minal) to communicate with the equipment of 
other geographically dispersed users. A packet 
assembler/disassembler (PAD), also referred to 
as data circuit-terminating equipment (DTE), 
serves as a network entry/exit point, packetizing 
and depacketizing data according to the rules 
specified by the X Series recommendations of 
the International Telecommunications Union’s 
Telecommunications Standardization Sector 
(ITU-TSS, formerly known as CCITT). 

In the early days of packet switching, each 
Public Data Network (PDN) defined its own net¬ 
work access protocol, which permitted an appro¬ 
priately equipped computer to communicate 
with other devices on the network through a 
physical connection to the PDN. Each of these 
protocols used a multiplexing technique that en¬ 
abled a computer to establish and maintain one 
or more virtual circuits to other network commu¬ 
nicating equipment. No industry standard for 
packet switching existed, however, and most 
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computer manufacturers were reluctant to pro¬ 
vide the necessary software to handle the variety 
of network access protocols. 

With the adoption of the X Series Recom¬ 
mendations by the ITU-TSS in 1976, the PDNs 
could offer a standard network access protocol. 
The ITU-TSS published revisions to these stan¬ 
dards in 1984 and 1989. Since that time, the rati¬ 
fication and publication of revisions have be¬ 
come a continuous, ongoing process. 

This report focuses on Recommendations 
X.3, X.28, and X.29 (informally called the Inter¬ 
active Terminal Interface [ITI] standards); X.21; 
X.25; and X.75. 


Packet Assembly/ 
Disassembly 

Recommendations X.3, X.28, and X.29 define 
the procedures by which asynchronous termi¬ 
nals, computers, and other devices, often re¬ 
ferred to as data terminal equipment (DTE), 
communicate with other devices via a packet 
switched network. Packet assemblers/disassem¬ 
blers, also referred to as DTE, commonly serve 
as network entry/exit points. 

X.3 defines the basic and user-selectable 
functions of a PAD. It also lists 22 parameters 
necessary to characterize a specific device (e.g., 
bit rate, the escape character, and flow control 
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technique). The proper setting of these values enables the PAD to 
correctly interpret the communicating device and vice versa. 

X.28, a related standard, defines the procedures for character 
interchange and service initialization, the exchange of control in¬ 
formation, and the exchange of user data between an asynchro¬ 
nous terminal device and a PAD. X.29 defines the procedures for 
the exchange of PAD control information and the manner in 
which user data is transferred between a packet mode DTE and a 
PAD or between two PADs. 

Recommendation X.3 

TSS Recommendation X.3, Packet Assembly/Disassembly Facil¬ 
ity in a Public Data Network , outlines the procedures for packet 
assembly/disassembly in asynchronous transmissions. These 
functions can be programmed and built into a microprocessor- 
based “black box” that is placed between the terminal and the 
X.25 network at either the customer’s premises or the entry point 
of the network node. 

The PAD performs a number of functions, some of which al¬ 
low it to be configured, by either an asynchronous terminal de¬ 
vice or another (remote) PAD, so that its operation is adapted to 
the asynchronous terminal’s characteristics. The PAD’S basic 
functions include the following: 

• The assembly of characters into packets; 

• The disassembly of the user data field; 

• Virtual call setup, clearing, resetting, and interrupt procedures; 

• Generation of service signals; 

• A mechanism for forwarding packets when the proper condi¬ 
tions exist; 

• A mechanism for transmitting data characters, including start, 
stop, and parity elements; 

• A mechanism for handling a break signal from an asynchro¬ 
nous terminal; 

• Editing of PAD command signals; 

• A mechanism for setting and reading the current value of PAD 
parameters; 

• A mechanism for the selection of a standard profile (optional); 

• Automatic detection of data rate, code, parity, and operational 
characteristics (optional); and 

• A mechanism for the remote DTE to request a virtual call be¬ 
tween an asynchronous terminal and another DTE (optional). 

The PAD’s operation depends on the selectable values of internal 
variables called PAD parameters. A set of parameters exists inde¬ 
pendently for each asynchronous terminal. The current value (the 
binary representation of the decimal value) of each PAD param¬ 
eter delimits the operational characteristics of the related func¬ 
tion. The initial value of each parameter is set according to a 
predetermined set of values, the initial standard profile. Twenty- 
two PAD parameters have been standardized by the ITU-TSS. 
They are as follows: 

• PAD recall using a character—allows an asynchronous ter¬ 
minal to initiate an escape from the data transfer state or the 
connection-in-progress state in order to send PAD command 
signals. This parameter has the following selectable values: not 
possible, possible by character 1/0 (DLE), or possible by a 
user-defined graphics character. 

• Echo—-enables characters received from the asynchronous ter¬ 
minal to be interpreted by the PAD and transmitted back to the 
asynchronous terminal. Selectable values are no echo (0) and 
echo(l). 
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• Selection of data forwarding characters—allows the asyn¬ 
chronous terminal to send defined sets of characters, which the 
PAD recognizes as an indication to complete the packet assem¬ 
bly and to forward a complete packet sequence as defined in 
X.25. The basic functions of this parameter are encoded and 
represented by a decimal value. The functions include no data 
forwarding character (represented by decimal 0); alphanumeric 
characters A-Z, a-z, and 0-9 (decimal 1); CR (decimal 2); ESC, 
BEL, ENQ, and ACK (decimal 4); DEL, CAN, and DC2 (deci¬ 
mal 8); ETX and EOT (decimal 16); HT, LF, VT, and FF (deci¬ 
mal 32); and all other characters in columns 0 and 1 of Interna¬ 
tional Alphabet No. 5 (IA5) not included in the above (decimal 
64). 

• Selection of idle timer delay—permits the selection of the 
duration of a time interval between successive characters. 
When data received from the asynchronous terminal exceeds 
this interval, the PAD terminates the assembly of a packet and 
forwards it as defined in the X.25 protocol. 

• Ancillary control—defines flow control between the PAD and 
the asynchronous terminal. Decimal 0 represents no use of 
X-on (DC1) and X-off (DC3); decimal 1 represents use of X- 
on/X-off (data transfer); and decimal 2 represents the use of 
X-on/X-off (data transfer and command). 

• Control of PAD service signals—provides the asynchronous 
terminal with the capability to decide whether and in what for¬ 
mat PAD service signals are transmitted. 

• Selection of operation of the PAD on receipt of the break 
signal—after receiving a break signal from the asynchronous 
terminal, the PAD may do nothing, send an interrupt packet to 
a packet mode DTE or another PAD, reset, or send an indica¬ 
tion of break PAD message to a packet mode DTE or another 
PAD. 

• Discard output—permits a PAD to discard the content of user 
sequences in packets rather than disassembling and transmit¬ 
ting them to the asynchronous terminal. Selections include nor¬ 
mal data delivery or discard output. 

• Padding after carriage return—permits the PAD to automati¬ 
cally insert padding characters in the character stream sent to 
the asynchronous terminal after the occurrence of a carriage 
return character. This enables the asynchronous terminal print¬ 
ing device to perform the carriage return function correctly. A 
value between 0 and 255 indicates the number of padding char¬ 
acters the PAD will generate. 

• Line folding—permits the PAD to automatically insert appro¬ 
priate format effectors in the character stream sent to the asyn¬ 
chronous terminal. No line folding or a predetermined maxi¬ 
mum number of graphics characters per line may be selected. 

• Binary speed—a read-only parameter that neither DTE can 
change. It enables the packet mode DTE to access a character¬ 
istic (known by the PAD) of the asynchronous terminal device. 
Speeds from 50 bps to 64K bps are represented. 

• Flow control of the PAD by the start/stop mode DTE—gov¬ 
erns flow control between the asynchronous terminal and the 
PAD. The asynchronous terminal transmits special characters 
to indicate whether it is ready to accept characters from the 
PAD. In IA5, these special characters switch an ancillary trans¬ 
mit device on and off. Decimal 0 represents no use of X-on 
(DC1) and X-off (DC3); decimal 1 represents use of X-on/X- 
off. 

• Line-feed insertion after carriage return—permits the PAD 
to automatically insert a line-feed character in the character 
stream sent to or received from the asynchronous terminal or 
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Table 1. TSS Recommendations—X Series 


TSS Description 

Recommendation 


X.1 

X.2 

X.3 

X.4 

X.20 

X.20 bis 

X.21 
X.21 bis 

X.24 

X.25 

X.26 

X.27 

X.28 

X.29 

X.32 

X.75 


X.92 

X.95 

X.96 

X.121 


International user classes of service in public data networks: class 8 (2400 bps); class 9 (4800 bps); 
class 10 (9600 bps); or class 11 (48,000 bps) 

International user facilities in public data networks 

Packet assembly/disassembly (PAD) facility in a public data network; lists options and defaults for 
interactive asynchronous terminal connection to X.25 packet networks 

General structure of signals of International Alphabet No. 5 (IA5) code for data transmission over public 
data networks (IA5 is described in TSS V.3) 

Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for 
async transmission services on public data networks 

V.21 -compatible interface between DTE and DCE for async transmission services on public data 
network 

General-purpose interface between DTE and DCE for synchronous operation on public data networks 

For use on public data networks by DTE that are designed to interface to synchronous V-Series 
modems 

List of definitions of interchange circuits between DTE and DCE on public data networks 
Interface between DTE and DCE for terminals operating in the packet mode on public data networks 

Electrical characteristics for unbalanced double-current interchange circuits for data communications 
equipment 

Electrical characteristics for balanced double-current interchange circuits for data communications 
equipment 

DTE/DCE interface for asynchronous device access to the PAD facility of a public data network in the 
same country 

Procedure for the exchange of control information and user data between a packet mode DTE and a 
PAD facility 

Procedure for communications between users and packet networks through the switched telephone 
network and through circuit switched public data networks 

Expanded X.25 recommendation for internetwork communications between packet switched networks; 
interface is defined between two STEs (Signaling Terminal Equipments) that are a part of ISDEs 
(International Data Switching Exchanges), with expanded support for wideband links, extended 
sequencing, and an expanded network utility field for international call establishment 

Hypothetical reference connections for public synchronous data networks 
Network parameters in public data networks 
Call progress signals in public data networks 

International numbering scheme for multinetwork communications containing a 4-digit DNIX (Data 
Network Identification Code), 3-digit area code, 5-digit host identification, a 0- to 2-digit subaddress 


after echo of each carriage return character. This function ap¬ 
plies only in the data transfer state. 

• Line-feed padding—permits the PAD to automatically insert 
padding characters in the character stream transmitted to the 
asynchronous terminal after the occurrence of a line-feed char¬ 
acter. This enables the asynchronous terminal printing mecha¬ 
nism to perform the line-feed operation correctly. This function 
applies only in the data transfer state. 

• Editing—enables character delete, line delete, and line display 
editing capabilities. During the PAD command state, the edit¬ 
ing function is always available; use or nonuse of the editing 
function in the data transfer state is selectable. 

• Character delete, line delete, and line display—all editing 
functions represented by one user-selectable character from 
IA5. 

• Editing PAD service signals—enable the asynchronous termi¬ 
nal to edit PAD service signals for printing devices and display 
terminals; also used for editing via one character from IA5. 
Editing is not selectable. 


• Echo mask—when echo is enabled, echo mask designates that 
selected defined groups of characters sent by the asynchronous 
terminal are not transmitted back. The following may be se¬ 
lected: no echo mask; no echo of CR; no echo of LF; no echo of 
VT, HT, and FF; no echo of BEL and BS; no echo of ESC and 
ENQ; no echo of ACK, NAK, STX, SOH, EOT, ETB, and 
ETX; no echo of editing characters; or no echo of all other 
characters. 

• Parity treatment—permits the PAD to check parity in the 
datastream from the asynchronous terminal and/or generate 
parity in the datastream to the asynchronous terminal. No par¬ 
ity checking or generation, parity checking, or parity genera¬ 
tion are selectable. 

• Page wait—allows the PAD to suspend transmission of addi¬ 
tional characters to the asynchronous terminal after the PAD 
has transmitted a specified number of line-feed characters. 

Recommendation X.28 

TSS Recommendation X.28, titled DTEIDCE Interface for a 

Start!Stop Mode Data Terminal Equipment Accessing the Packet 
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Assembly/Disassembly Facility (PAD) in a Public Data Network 
Situated in the Same Country , describes the interfacing proce¬ 
dures that allow the PAD to be connected to an asynchronous 
terminal. X.28 covers four areas: 

• Procedures to establish an access information path between an 
asynchronous terminal and a PAD; 

• Procedures for character interchange and service initialization 
between an asynchronous terminal and a PAD; 

• Procedures for the exchange of control information between an 
asynchronous terminal and a PAD; and 

® Procedures for the exchange of user data between an asynchro¬ 
nous terminal and a PAD. 

Modems standardized for use on public switched or leased line 
facilities establish the procedures for providing an access path 
(DTE/DCE interface). Procedures for both V and X Series inter¬ 
faces are defined. 

Transmission speeds up to 1200 bps are specified for V-Series 
interfaces; they are in accordance with either the V.21, V.22, or 
¥.23 standard, depending on facility type and speed. The V-Series 
specifications define the procedures for setting up and discon¬ 
necting the access information path by both the DTE and the 
PAD. 

X-Series interfaces also are used with switched or leased line 
facilities. The physical characteristics for the DTE/DCE interface 
are specified in X.20 or X.20 bis. Procedures for setting up and 
disconnecting the path by both the DTE and the PAD are defined. 

X.28 specifies procedures for character interchange and ser¬ 
vice initialization between an asynchronous terminal and a PAD. 
Characters sent and received must conform to IA5. The PAD 
transmits and expects to receive only eight-bit characters. The 
eighth bit, the last bit preceding the stop element, is used for 
parity checking. 

X.28 describes the action the PAD takes when the value of 
parameter 21 (X.3, parity treatment) is set to 0, 1, 2, or 3. If 
parameter 21 is set to 0, the PAD inspects only the first seven bits 
and ignores the eighth bit. When parameter 21 is set to 1, the PAD 
treats the eighth bit of the character as a parity bit and checks this 
bit against the type of parity—odd, even, space (0), or mark (1)— 
used between the PAD and the asynchronous terminal. If it is set 
to 2, the PAD replaces the eighth bit of the characters to be sent to 
the terminal with the bit that corresponds to the type of parity 
used between the PAD and terminal. When the value is set to 3, 
the PAD checks the parity bit for characters received from the 
asynchronous terminal and generates the parity bit for characters 
to be sent to the asynchronous terminal (as in values 1 and 2). 

Once the access information path is established, the asynchro¬ 
nous terminal and the PAD exchange binary 1 across the inter¬ 
face. This places the interface in the active link state (state 1). 
When the interface is in the active link state, the DTE transmits a 
sequence of characters that indicates service request (state 2) and 
initializes the PAD. The service request permits the PAD to detect 
the data rate, code, and parity used by the asynchronous terminal 
(DTE) and to select the initial profile of the PAD. The service 
request may be bypassed, if the terminal is connected to the PAD 
via a leased line and the PAD knows the speed, code, and initial 
profile of the terminal or if a default value is used. After the 
request service signal is transmitted, the DTE transmits binary 1, 
which places the interface in the DTE waiting state (state 3 A). If 
parameter 6 (X.3, control of PAD service signals) is set to 0, the 
interface immediately enters the PAD waiting state (state 5) after 
receipt of service request. If parameter 6 is set to other than 0, the 
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PAD transmits the PAD identification PAD service signal (indi¬ 
cates PAD and port identity; is network dependent), and the inter¬ 
face enters the service ready state (state 4). The DTE then trans¬ 
mits a selection PAD command signal (state 6), and the PAD 
transmits an acknowledgment PAD service signal, followed by 
binary 1, which places the interface in the connection-in-progress 
state (state 7). 

If parameter 6 is 0, the PAD will not transmit PAD service 
signals. In this case, the interface is placed in the connection-in- 
progress state after receipt of a valid selection PAD command 
signal. 

Once the DTE receives the PAD service signal (state 8) or a 
sequence of signals in response to a PAD command signal, the 
interface is placed in either the PAD waiting state (state 5) or the 
data transfer state (state 9). 

A fault condition exists if a valid service request signal is not 
received by the PAD within a selectable number of seconds after 
the transmission of binary 1. If a fault condition occurs, the PAD 
performs clearing by disconnecting the access information path. 

The procedures for the exchange of control information be¬ 
tween an asynchronous terminal and a PAD include PAD com¬ 
mand signals, PAD service signals, break signals, and prompt 
PAD service signals. PAD command signals flow from the DTE 
to the PAD; they set up and clear a virtual call, select a standard 
profile (PAD parameters) that is either ITU-TSS or network de¬ 
fined, request current values of PAD parameters, send an interrupt 
requesting circuit status, and reset a virtual call. PAD service sig¬ 
nals flow from the PAD to the DTE; they transmit call progress 
signals, acknowledge PAD command signals, and transmit oper¬ 
ating information of the PAD to the terminal. Either the PAD or 
the terminal can transmit the break signal. It provides signaling 
without losing character transparency. The prompt PAD service 
signal indicates the PAD’S readiness to receive a PAD command 
signal. 

The temporary storage of characters in an editing buffer pro¬ 
vides editing functions in the PAD. These functions permit the 
asynchronous terminal to edit characters input to the PAD before 
the PAD processes them. They include character delete, line de¬ 
lete, and line display. Character delete removes the last character 
in the editing; line delete removes the contents of the editing 
buffer. Line display causes the PAD to send a format effector 
followed by the contents of the editing buffer to the terminal. 

Procedures for the exchange of user data between an asyn¬ 
chronous terminal and a PAD apply during the data transfer state. 
The values of the parameters set in X.3 determine which charac¬ 
ters are transmitted during the data transfer state. For example, if 
parameters 1 (PAD recall using a character), 12 (flow control of 
the PAD by the start/stop mode DTE), 15 (editing), and 22 (page 
wait) are set to 0, any character sequence may be transmitted by 
the asynchronous terminal for delivery to the remote DTE during 
the data transfer state. 

User data is sent to the asynchronous terminal in octets (eight- 
bit characters) at the appropriate transmission rate for the asyn¬ 
chronous terminal; the start/stop bits are added to the data char¬ 
acters. Octets are assembled into packets (see X.25) and 
forwarded when enough data has been received to fill a packet, 
when the maximum assembly timer delay period has elapsed, 
when a data forwarding character is transmitted, or when a break 
signal is transmitted (parameter 7 is set to other than 0). 

Recommendation X.29 

TSS Recommendation X.29, titled Procedures for the Exchange 
of Control Information and User Data Between a Packet Assem¬ 
bly/Disassembly Facility (PAD) and a Packet Mode DTE or An¬ 
other PAD , provides the final step. X.29 describes the interfacing 
procedures that allow the PAD to communicate with the X.25 
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network. It defines the procedures for the exchange of PAD con¬ 
trol information and the manner in which user data is transferred 
between a packet mode DTE and a PAD or between two PADs. 

Recommendation X.29 specifies that control information and 
user data are exchanged between a PAD and a packet mode DTE 
or between PADs using the data fields described in X.25. Inter¬ 
face characteristics—mechanical, electrical, functional, and pro¬ 
cedural—are also defined as in X.25. 

X.29 specifies that the call user data field of an incoming call 
or call request packet going to/from the PAD or the packet mode 
DTE must consist of protocol identifier and call data fields. A call 
request packet need not contain a call user data field to be ac¬ 
cepted by the PAD. If the call user data field is present, the PAD 
transmits it, unchanged, to its destination. 

A call data field’s octets consist of user characters sent from 
the DTE to the PAD during the call establishment phase. This 
field is limited to 12 octets. The octet’s bits are numbered 8 to 1; 
bit 1, the low order bit, is transmitted first. 

Bits 8, 7, 6, and 5 of octet 1 of a user data field of complete 
packet sequences are the control identifier field. This field, which 
consists of four octets, identifies the facility to be controlled. The 
control identifier field coding for messages to control a PAD for 
an asynchronous terminal is 0000. When the control identifier 
field is set to 0000, bits 4, 3,2, and 1 of octet 1 are defined as the 
message code field, which is used to identify specific types of 
PAD messages. 

User sequences perform data exchange. They are transferred 
in the user data fields of complete packet sequences with the Q bit 
set to 0. Only one user sequence exists per complete packet se¬ 
quence. The PAD transmits all data packets with the D bit set to 0. 
The DTE sends a data packet to the PAD with the D bit set to 1. 
When the PAD receives a data packet with the D bit set to 1, it 
sends the corresponding acknowledgment. The PAD may reset 
the virtual call, if it does not support the D bit procedure. 


Table 2. TSS X.21 Interchange Circuits 


Direction 


Interchange Name 

to DCE 

from DCE 

Circuit 

Circuit 




Type 

G 

Signal 
ground or 





common 

return 




Ga 

DTE 

common 

return 

X 


Ground 

Gb 

DCE 

common 

return 


X 


T 

Transmit 

X 


Data 

Transfer 

R 

Receive 


X 


C 

1 

Control 

Indication 

X 

X 

Control 

S 

Signal 

element 

timing 


X 


B 

Byte timing 


X 

Timing 


Control information is exchanged via PAD messages , which 
contain a control identifier field and a message code field that 
may be followed by a parameter field. PAD messages are trans¬ 
ferred in the user data fields of complete packet sequences with 
the Q bit set to 1. Only one PAD message exists per complete 
packet sequence. The PAD sends all data packets with the D bit 
set to 0. The DTE may send data packets to the PAD with both the 
D bit and the Q bit set to 1. When the PAD receives a data packet 
with both the Q and D bits set to 1, the corresponding acknowl¬ 
edgment is transmitted. The PAD may reset the virtual call if it 
does not support the D bit procedure. (Figure 5 shows the bit 
positions for the Q and D bits.) 

The PAD forwards a data packet when a set, read , or set and 
read PAD message is received or when any of the conditions 
listed in X.28 exist (e.g., enough data has been received to fill a 
packet, the maximum assembly timer delay period has elapsed, or 
a data forwarding character is transmitted). The PAD never for¬ 
wards an empty Data packet. 

By sending a set , read , or set and read message to the PAD, 
one can read and change the current values of PAD parameters. 
Upon receipt of one of these messages, the PAD delivers to the 
DTE any previously received data before it acts on the PAD mes¬ 
sage. The PAD responds to a read or set and read PAD message 
by sending a parameter indication PAD message, which contains 
a parameter field listing parameter references and current values. 
Set allows the changing of parameters. 

X.29 also discusses invitation to clear procedures, which are 
used to request that the virtual call be cleared by the PAD; inter¬ 
rupt and discard procedures, which are used to indicate that the 
asynchronous terminal has requested that the PAD discard re¬ 
ceived user sequences; reset procedures, as defined in X.25; error 
handling procedures by the PAD , which define the actions to be 
taken by the PAD when errors are detected; and procedures for 
inviting the PAD to reselect the called DTE (optional), which are 
used by a packet mode DTE to request that the PAD clear the 
virtual call. 


X.21 Interface Specifications 

The trends in communications engineering lean toward all-digital 
networks and the integration of voice and data. Prospective users 
of these digital, integrated networks are concerned about an inter¬ 
face that can provide access to voice, data, video teleconferenc¬ 
ing, and related services. Currently, a wide variety of connectors, 
electrical standards, and user procedures for various services and 
networks exists—leading to almost insurmountable technical and 
economical problems. Therefore, it is likely that standards orga¬ 
nizations will develop a universal service access interface. Al¬ 
though it would require certain extensions, X.21 is currently the 
most likely to become a future standard for a universal interface 
in distributed system implementations. 

TSS Recommendation X.21, Interface Between Data Termi¬ 
nal Equipment (DTE) and Data Circuit-Terminating Equipment 
(DCE) for Synchronous Operation on Public Data Networks , de¬ 
fines the physical characteristics and control procedures for an 
interface between DTEs and DCEs. 

X.21 is the designated interface for TSS Recommendation 
X.25, a packet-switching protocol. X.21 can also be used in a 
non-packet switched environment. At least two X.21-based pub¬ 
lic data circuit switched networks are currently implemented, one 
in Scandinavia and one in Japan. 

The X.21 standard has not gained wide acceptance in the 
United States. The reluctance in the U.S. to embrace the X.21 
standard is due in part to the firm entrenchment of RS-232-C. 
Another factor is the cost of implementing X.21. Since X.21 


© 1994 McGraw-Hill, Incorporated. Reproduction Prohibited. 
Oatapro Information Services Group. Delran NJ 08075 USA 


FEBRUARY 1994 



6 


Data Networking 


2790 

Standards 


transmits and interprets coded character strings, more intelligence 
must be built into the interface, at a higher cost than traditional 
pin-per-function interfaces. 

Certain characteristics of X.21 should ensure a more wide¬ 
spread acceptance in the coming years. One immense advantage 
X.21 has over traditional interfaces is its capability to assign an 
almost unlimited number of functions, because there are no func¬ 
tional boundaries associated with connector size. Also, X.21 of¬ 
fers a much more sophisticated level of control over the commu¬ 
nications process. Another important feature of X.21 is its 
inherent dialing functions, including the provision for reporting 
the reasons why a call was not completed. This eliminates the 
need for a separate data call interface, such as RS-232-C’s com¬ 
panion RS-366-A, and in switched facilities, results in improved 
response times. 

Another important aspect is its relationship to X.25. As the 
packet-switching technique becomes more widely implemented, 
the demand will be greater for equipment to meet the X.21 stan¬ 
dard. Internationally, the combination of X.21, the ISO HDLC 
protocol, and X.25 has been used to form an effective communi¬ 
cations path. Another boost for X.21 is IBM’s recognition. 

X.21 has some shortcomings. It does not permit the transmis¬ 
sion of control information during data transfer. Also, it precludes 
the insertion of data encryption hardware between the DTE and 
the DCE. Another drawback is the need to modify the DTE/DCE 
master/slave protocol techniques and to supply special crossover 
cables to facilitate DTE-to-DTE or DCE-to-DCE interconnec¬ 
tion. 

X.21 uses a different interfacing technique than that which is 
normally associated with physical-level interfaces. Instead of as¬ 
signing each function a specific pin on the connector (e.g., V.24 
and EIARS-232), X.21 assigns coded character strings to each 
function. 

The following is a summary of the X.21 standard, including 
the functional descriptions of the interchange circuits, phases of 
operation, electrical characteristics, and mechanical characteris¬ 
tics. 

Functional Descriptions of Interchange Circuits 

Four types of X.21 interchange circuits are defined: Ground, Data 
Transfer, Control, and Timing. These circuits, outlined in Table 2, 
are described below. 

Ground and Common Return Circuits—include two types 
of common return circuits, DTE Common Return and DCE Com¬ 
mon Return, and one ground circuit, Signal Ground. 

Signal Ground (Circuit G) establishes the common reference 
potential for unbalanced double-current interchange circuits. If 
required, it reduces environmental signal interference. 

Lowering signaling rates may require two common return 
conductors. In this case, two circuits, DTE Common Return (Cir¬ 
cuit Ga) and DCE Common Return (Circuit Gb), are necessary. 
For a further explanation of these circuits, see the Electrical Char¬ 
acteristics section of this report. 

Data Transfer Circuits—include two Transmit and Receive 
data transfer circuits. 

Transmit (Circuit T) transfers signals from the DTE to the 
DCE during the data transfer phase. It also transfers call control 
signals to the DCE during call establishment and other call con¬ 
trol phases. 

Receive (Circuit R) receives signals transmitted by the DCE 
from a remote DTE during the data transfer phase. This circuit 
also transfers call control signals from the DCE during the call 
establishment and other call control phases. 

Control Circuits—include Control and Indication circuits. 

Control (Circuit C) transmits signals that control the DCE for 
a particular signaling process. The representation of this signal 
requires additional coding of the Transmit circuit, as specified for 
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the procedural characteristics of the interface. During the data 
phase, Circuit C remains in the ON condition. 

Indication (Circuit I) indicates the call control process to the 
DTE. The representation of this signal requires additional coding 
of the Receive circuit. When Circuit I is on, it signifies that sig¬ 
nals on the Receive circuit contain information from the remote 
DTE. When Circuit I is off, it signifies a control signaling condi¬ 
tion, defined by the Circuit R bit patterns, as specified by the 
procedural characteristics of the interface. 

Timing Circuits—includes Signal Element Timing and Byte 
Timing. 

Signal Element Timing (Circuit S) provides the DTE with sig¬ 
nal element timing information. For this function, Circuit S turns 
on and off for nominally equal periods of time. 

X.21 defines different roles for the DTE and DCE in regard to 
signal element timing. During the off-to-on transition, the DTE 
presents a binary signal on Circuit T and a condition on Circuit C. 
The DCE presents a binary signal on Circuit R and a condition on 
Circuit I during the off-to-on transition. The DCE transfers the 
signal element timing across the interface as long as the timing 
source is capable of generating this information. 

Byte Timing (Circuit B) provides the DTE with eight-bit tim¬ 
ing information for synchronous transmission. Use of this circuit 
is not mandatory. Circuit B turns off whenever Circuit S is in the 
ON condition, indicating the last bit of the eight-bit byte. At all 
other times within the period of the eight-bit byte, Circuit B re¬ 
mains on. 

Phases of Operation 

The X.21 standard defines four phases of operation: the Quies¬ 
cent Phase, the Call Control Phase, the Data Transfer Phase, and 
the Clearing Phase. 

Each step of the operational phases places the DTE and DCE 
in a certain state. See Table 3 for a listing of these states and their 
associated signals on the interchange circuits. 

Quiescent Phase—the quiescent phase is the period during 
which the DTE and the DCE signal their capability to enter the 
call control phase or the data transfer phase. It is characterized by 
the appearance of basic quiescent signals from the DTE and DCE. 
Various combinations of these quiescent signals result in different 
interface states, or quiescent states. 

There are three DTE quiescent signals. DTE Ready indicates 
the readiness of the DTE to enter the other operational phases. 
DTE Uncontrolled Not Ready indicates the DTE is incapable of 
entering certain operational phases, usually due to an abnormal 
condition. DTE Controlled Not Ready indicates that although the 
DTE is operational, it is temporarily incapable of accepting in¬ 
coming calls for circuit switched service. 

There are two DCE quiescent signals: DCE Ready and DCE 
Not Ready. DCE Ready indicates the DCE is ready to enter op¬ 
erational phases. DCE Not Ready indicates that no service is 
available; it is also signaled whenever possible during network 
fault conditions and during the period when test loops are acti¬ 
vated. 

There are six quiescent states: 

• Ready 

• DTE Controlled Not Ready, DCE Ready 

• DTE Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Not Ready 

• DTE Controlled Not Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Ready 

See Figure 1 for a diagram of the quiescent states and the transi¬ 
tions that are allowed between these states. 
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Table 3. X.21 States: Names, Signalling, and Transitions 

Signals on T,C and R,l Circuits 

Phase 

of 

State Opera- 

Number State Name tion T C R 1 

DTE 
to state 
number 

Transitions* 

DCE 
to state 
number 

1 

Ready 

Q 

1 

OFF 

1 

OFF 

2,13S,14,24 

8,13R,18 

2 

Call request 

CC 

0 

ON 

1 

OFF 

- 

3,15 

3 

Proceed-to-select 

CC 

0 

ON 

+ 

OFF 

4,15 

- 

4 

Selection signal 

CC 

IA5 

ON 

+ 

OFF 

5 

- 

5 

DTE Waiting 

CC 

1 

ON 

+ 

OFF 

- 

6A,11,12 

6A 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

- 

7,10,11,12 

6B 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

- 

10 bis, 11,12 

7 

Call progress signal 

CC 

1 

ON 

IA5 

OFF 

- 

6A,10,11,12 

8 

Incoming call 

CC 

1 

OFF 

BEL 

OFF 

15,9 

- 

9 

Call accepted 

CC 

1 

ON 

BEL 

OFF 

- 

6B,11,12 

10 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

- 

6A,11,12 

10 bis 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

- 

6B,11,12 

11 

Connection in progress 

CC 

1 

ON 

1 

OFF 

- 

12 

12 

Ready for data 

CC 

1 

ON 

1 

ON 

- 

13 

13 

Data transfer 

DT 

D 

ON 

D 

ON 

13R 

13S.DCE 









not ready 

13R 

Receive data 

DT 

1 

OFF 

D 

ON 

13 

1 

13S 

Send data 

ET 

D 

ON 

1 

OFF 

7 

13 

14 

DTE Controlled not ready, DCE 









ready 

Q 

01 

OFF 

1 

OFF 

1,24 

23 

15 

Call collision 

CC 

0 

ON 

BEL 

OFF 

- 

3 

16 

DTE Clear request 

C 

0 

OFF 

X 

X 

- 

17 




(see 









Note) 






17 

DCE Clear confirmation 

c 

0 

OFF 

0 

OFF 

_ 

21 

18 

DTE Ready, DCE Not ready 

Q 

1 

OFF 

0 

OFF 

22 

1 

- 

DCE Not ready 

Q 

D 

ON 

0 

OFF 

- 

1.13.13S 

19 

DCE Clear indication 

C 

X 

X 

0 

OFF 

20 

- 




(see 









Note) 






20 

DTE Clear confirmation 

C 

0 

OFF 

0 

OFF 

_ 

21 

21 

DCE Ready 

C 

0 

OFF 

1 

OFF 

1 

- 

22 

DTE Uncontrolled not ready, DCE 









not ready 

Q 

0 

OFF 

0 

OFF 

18 

24 

23 

DTE Controlled not ready, DCE not 









ready 

Q 

01 

OFF 

0 

OFF 

18,22 

14 

24 

DTE Uncontrolled not ready, DCE 









ready 

Q 

0 

OFF 

1 

OFF 

1 

22 

Any 









state 









(see 









Note) 



X 

X 

X 

X 

16 

19 


*AII other transitions are considered invalid. 

Note: DCE Clear indication or DTE Clear request may be entered from any state except Ready. 


Key to Table: 

Q-Quiescent Phase 
CC-Call Control Phase 
DT-Data Transfer Phase 
T-Transmit interchange circuit 
G-Control interchange circuit 
R-Receive interchange circuit 
Indication interchange circuit 


0 and 1-Steady binary conditions 
01-Alternate binary 0 and binary 1 
X-Any value 

OFF-Continuous off (binary 1) 
ON-Continuous on (binary 0) 
IA5-Characters from CCITT Alphabet #5 
+-IA5 character 2/11 
BEL-IA5 character 0/7 
SYN-IA5 character 1/6 
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Figure I. 
Quiescent States 



Definitions: 


I 



♦ 


n State number 
t Signal on T circuit 

c Signal on C circuit 

r Signal on R circuit 

i Signal on I circuit 


I 


Transition with indication 
of whether DTE or DCE 
is responsible for transition 


The above diagram indicates transitions that are allowed in X.21 networks. Other transitions are possible and may be allowed in some networks. 
See Table 3 for a listing of possible transitions. 


Call Control Phase—-the call control phase for circuit 
switched service contains many elements and procedures. Char¬ 
acters used for call control are selected from IA5, a seven-bit plus 
parity international code outlined in TSS Recommendation V.3. 
Each call control sequence to and from the DCE is preceded by 
two or more continuous SYN characters. For error checking of 
call control characters, odd parity is specified. 

The following elements of the call control procedure are out¬ 
lined in X.21: events of call control procedures, unsuccessful call, 
call collision, direct call, and facility registration/cancellation 
procedure. These elements are summarized below. 

The events of the call control procedures include the follow¬ 
ing: 

• Call Request, signaled by the DTE to indicate a request for a 
call. 

• Proceed to Select , used when the network is prepared to receive 
selection information. It is transmitted by the DCE to the DTE 
within three seconds of the call request signal. 

• Selection Signal Sequence , transmitted by the DTE. A selection 
sequence consists of a facility request block, an address block, 
a facility request block followed by an address block, or a fa¬ 
cility registration/cancellation block. A facility request block 
comprises one or more facility request signals, which consist of 
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a facility request code containing one or more facility param¬ 
eters. An address block contains one or more address signals. 
Address signals consist of either a full address signal or an 
abbreviated address signal. 

• DTE Waiting. 

• Incoming Call, indicated by the DCE. In response, the DTE 
signals Clear Request, DTE Uncontrolled Not Ready, or DTE 
Controlled Not Ready. 

• DCE Waiting. 

• Call Progress Signal Sequence is transmitted by the DCE to the 
calling DTE to indicate that circumstances have arisen to pre¬ 
vent the connection from being established, to report the 
progress made toward establishing the call, or to signal that 
problems have been detected and that the call needs to be 
cleared and reset. 

• DCE-Provided Information Sequence , transmitted from the 
DCE to the calling DTE. It consists of DCE-provided informa¬ 
tion blocks, such as line identification and charging informa¬ 
tion. Line Identification is transmitted by the DCE to the call¬ 
ing DTE during the DCE-Provided Information state 
immediately after all call progress signals, if any, are transmit¬ 
ted. Both calling and called line identification are optional. 
Line identification consists of the international data number, as 
assigned in TSS Recommendation X.121, International Num¬ 
bering Plan for Public Data Networks. The DCE transmits 
Charging Information during the DCE-Provided Information 
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state. It informs the subscriber of either the monetary charges 
for a call, the duration of the call, or the number of units used 
during the call. 

• Connection-In-Progress , indicated by the DCE. 

• Ready for Data , transmitted by the DCE when the connection 
is available for data transfer between DTEs. 

An unsuccessful call occurs when a required connection cannot 
be established. In this case, the DCE indicates the failure and its 
reason to the calling DTE through a call progress signal. 

A call collision can occur in one of two ways: a DTE detects a 
call collision when it receives Incoming Call in response to Call 
Request. A DCE detects a call collision when it receives Call 
Request in response to Incoming Call. When the DCE detects a 
call collision, it will indicate Proceed to select and cancel the 
incoming call. 

The DTE indicates a request for a direct call by signaling DTE 
Waiting after receiving the Proceed to Select signal. If necessary, 
the DTE may choose an addressed call by presenting the correct 
Selection signal. 

The facility registration/cancellation procedure is optional. A 
facility registration/cancellation signal consists of up to four ele¬ 
ments in order: facility request code, indicator, registration pa¬ 
rameter, and address signal. Not all of these elements are required 
in the facility registration/cancellation signal. Also, a number of 
these signals may be linked to form a block. In response to accep¬ 
tance or rejection of the facility registration/cancellation action, 
the network provides the appropriate Call Progress Signal. 

Data Transfer Phase—when the DTE is in the data transfer 
phase, any bit sequence may be transmitted. X.21 defines the data 
transfer phase for three types of connections: switched; leased, 
point to point; and leased, centralized multipoint. 


Table 4. 

X.21 Pin Assignments 

Pin 

Employing 

Employing 

Number 

X.26 

X.27 

1 

See Note (3) 

See Note (3) 

9 

Ga 

T(B) 

2 

T 

T(A) 

10 

Ga 

C(B) 

3 

C 

C(A) 

11 

R(B) 

R(B) 

4 

R(A) 

R(A) 

12 

KB) 

1(B) 

5 

1(A) 

1(A) 

13 

S(B) 

S(B) 

6 

S(A) 

S(A) 

14 

B(B) 

B(B) 

7 

B(A) 

B(A) 

15 

Reserved for 

Reserved for 


future use 

future use 

8 

G 

G 


Notes: 

(1) X.21 pin assignments are defined by ISO 4903-1980. 

(2) Where balanced ciruits are, the associated pairs are 
designated “A”and “B.” 

(3) Pin 1 is reserved for connection of the shield or shielded 
interconnecting cable. 


For operation over switched facilities, the DTE may send bits 
to a corresponding DTE after receiving the Ready for Data signal. 
During data transfer, control and interchange circuits are in the 
ON condition, and data is transmitted over the transmit and re¬ 
ceive circuits. Data transfer may be terminated by clearing , 
which is defined below. 

Two basic signals are used for operation over leased, point-to- 
point facilities. Send Data transmits data by the DTE on Circuit T, 
the remote DTE’s Receive Data signal receives data over Circuit 
R. To terminate the data transfer, the DTE signal places its trans¬ 
mit circuit in the binary 1 condition. The DCE indicates termina¬ 
tion of data transfer by placing its receive circuit in the binary 1 
condition, its control circuit in the OFF condition, and its indica¬ 
tions circuit in the OFF condition. 

Both the central and remote DTEs use the Send Data and Re¬ 
ceive Data signals for operation over leased, multipoint facilities. 
The central DTE delivers data transmitted to all remote DTEs; 
remote DTEs (one at a time) transmit data to the central DTE. A 
remote DTE may send data to the central DTE while the central 
DTE is sending to all remote DTEs. 

Clearing Phase—either the DTE or the DCE may initiate 
clearing. The DTE indicates its desire to enter the clearing phase 
by transmitting DTE Clear Request. The DCE responds by sig¬ 
naling DCE Clear Confirmation , followed by DCE Ready. 

Clearing by the DCE takes place when it transmits DCE Clear 
Indication. The DTE responds with the DTE Clear Confirmation 
signal, followed by the DCE signaling DCE Ready. 

Electrical Characteristics 

X.21 uses two types of electrical characteristics, each for different 
system requirements. 

For synchronous operation at 9600 bps and below, the inter¬ 
change circuits at the DCE side of the interface must comply with 
TSS Recommendation X.21. The DTE side can comply with ei¬ 
ther X.21 or another TSS Recommendation, X.26. For synchro¬ 
nous operation at signaling rates above 9600 bps, interchange 
circuits at both the DTE and DCE sides of the interchange circuits 
must comply with X.21. 

X.26 is defined in TSS Standard V.10. It describes the electri¬ 
cal characteristics for unbalanced interchange circuits. X.26 calls 
for both a DTE and DCE common grounding arrangement. The 
maximum suggested cable length is 1,000 meters, and the maxi¬ 
mum data rate is 100K bps. 

X.21 is defined by TSS Standard V.ll, which describes the 
electrical characteristics for balanced operation. Maximum sug¬ 
gested cable length is 1,000 meters, and the maximum data rate is 
10M bps. 

Mechanical Characteristics 

The mechanical characteristics for X.21 are outlined in the ISO 
Standard 4903, approved by the International Organization for 
Standardization (ISO). The standard, entitled Data Communica¬ 
tion — 15-pin DTE/DCE Interface Connector and Pin Assign¬ 
ments , was published in June 1980. 

ISO 4903 assigns connector pin numbers to a 15-pin interface 
between DTE and DCE equipment. Table 4 presents a chart of 
these X.21 pin assignments as they relate to the X.26 and X.21 
standards. 

X.21 Bis 

Although X.21 is the specified interface for X.25, alternative in¬ 
terfaces also exist. One of these is X.21 bis. 

TSS Recommendation X.21 bis, the physical and functional 
equivalent to TSS V.24, defines 25 interchange circuits between 
DTEs and DCEs. TSS V.24 is compatible with EIA Standard RS- 
232-C. The X.21 bis recommendation, accepted as the interim 
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Figure 2. 

A Sample User Terminal Configuration for Operating on a Public Data Network (PDN) in Packet Mode , with X.25 as the Interface to the 
Network 



0 Signifies an interface that must conform to X.25 Level 2, Physical Interface Standards. 


interface for X.25, will be gradually replaced by X.21 as more 
equipment is manufactured to meet X.21 specifications. 

Recommendation X.25 

The development of Recommendation X.25 was stimulated by 
the need for a standard interface between the packet-switching 
networks already developed or being developed by many indus¬ 
trial nations and by the requirement that no terminal equipment be 
denied access to packet switched services. 

X.25 is a dynamic standard with many variations in the U.S. 
and abroad. Currently, X.25-based packet switched networks ex¬ 
ist in Australia, Austria, Belgium, Canada, France, Ireland, Ger¬ 
many, Hong Kong, Italy, Japan, Mexico, the Netherlands, Portu¬ 
gal, Singapore, the Soviet Union, South Africa, Spain, 
Switzerland, the United Kingdom, and the United States. Since 
X.25 is a dynamic standard with many extensions and optional 
features, these networks are not totally compatible with one an¬ 
other. Those located in Europe have the highest level of mutual 
compatibility. 
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Since the establishment of X.25, additional user-level proto¬ 
cols have been developed. These protocols provide the interfaces 
between different types of terminals and the X.25 interface. X.3, 
X.28, and X.29, informally called the Interactive Terminal Inter¬ 
face (ITI), were the first of the protocols to interface to X.25. 
They relate to the support of asynchronous, low-speed terminals 
by packet switched networks. These are logical complements to 
X.25 because they permit specific sets of terminals to interface to 
the packet networks using the X.25 interface. 

The X.25 interface standard provides for the connection of 
terminals and computers to public packet-switching networks. 
X.25 outlines three layers of operation: the Physical Layer, the 
Link Layer, and the Packet Layer. These layers parallel the bot¬ 
tom three layers of the ISO Reference Model for Open Systems 
Interconnection. The Physical Layer calls for TSS X.21 as the 
physical and electrical interface but accepts X.21 bis, a functional 
equivalent of RS-232-C, as an interim standard. The Link Layer 
uses the procedures of the HDLC protocol standard. The Packet 
Layer defines procedures for constructing and controlling a data 
packet. 
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The 1984 revision of Recommendation X.25 added specifica¬ 
tions for X.21 access and expanded the potential of packet opera¬ 
tions, allowing users to actively gain access to the X.25 port, 
identify themselves, and validate their connection through pass¬ 
words. This change reoriented the X.25 standard toward switched 
access through both X.21 facilities and the public telephone net¬ 
work. It now supports X.32 with regard to the public switched 
telephone network or a circuit switched public data network, 
dial-in and dial-out access, backup for leased line connections, 
long-distance access to the network, and teletex. 

Datagram was deleted in 1984, while the following packet- 
level services were made available as options: 

• Registered Private Operating Agent (RPOA) Selection per¬ 
mits the use of one or more networks to route a call to its 
destination. If the user selects only one network, either the ba¬ 
sic or extended format of the RPOA Selection can be used; if 
more than one network is chosen, the extended format is used. 

• Call Redirection permits the rerouting of calls if the first tried 
route fails. 

• Call Redirection Notification informs the recipient of the for¬ 
warded call that the call has been redirected. 

• Called Line Address Modified Notification tells the caller, 
within a call confirmation packet, that the call has been redi¬ 
rected. 

• Hunt Group distributes incoming calls that have an address 
associated with the hunt group. 

• Charging Information gives the caller information on time 
and charges and requires a new field in the call-clearing packet 
format. 

• Local Charging Prevention is a security facility that prevents 
reverse or third-party call charges. 

• Network User Identification accommodates user ID, billing, 
and online facilities registration. This permits users to commu¬ 
nicate directly with the packet data network to change the pa¬ 
rameters of their subscriptions. 

The packet level is an octet-oriented (eight bits per octet) struc¬ 
ture. Packet sizes can vary from 1,024 to 2,048 octets, but only 
within a network. Network-to-network exchange is limited to 128 
octets. Closed user group facilities can accommodate very large 
private-packet networks, although the number of closed user 
groups to which a DTE can belong is network dependent. (See 
Figure 3.) 

Link-level changes implemented in 1984 created a clear sepa¬ 
ration between the Link Access Procedure (LAP) and the Link 
Access Procedure Balanced (LAPB). Multilink procedures for a 
single interface were also implemented. LAPB underwent an 
alignment with the single-link procedure of X.75. An extended 
numbering option (modulo 128) was added to LAPB to enable the 
sequencing of 127 frames and the use of satellite facilities. In 
addition, the 1984 revisions to X.25 refined the procedure for the 
implementation of the D-bit, polished technical accuracy, and de¬ 
fined the rules for new fields and formats. 

X.25 Communications 

X.25 is titled Interface Between Data Terminal Equipment (DTE) 
and Data Circuit-Terminating Equipment (DCE) for Terminals 
Operating in the Packet Mode on Public Data Networks. It pro¬ 
vides a precise set of procedures for communications between 
DTE and DCE for terminal equipment operating in a packet en¬ 
vironment. The DCE in this case is a node processor that serves as 
an entry/exit point on the packet network side of the user/network 
interface. 


The Data Terminal Equipment is a programmable device on 
the user side of the user/network interface. The DTE is located at 
the user site when the onsite equipment supports X.25; at such 
installations, the DTE can be either a computer, a front-end pro¬ 
cessor, or an intelligent terminal, as shown in Figure 2. The DTE 
can be a group of intelligent terminals (multiplexed to avoid the 
use of multiple lines) that transmit data over the packet network 
to a remotely located host. It can also be a processor acting on 
calls received from multiple locations that communicate over the 
packet network. 

Regardless of the device or application, all DTEs present stan¬ 
dard formatted data and control information to the DCE over 
standard communications facilities. Devices operate over the net¬ 
work in the virtual circuit mode. Essentially, the user causes the 
network to establish a logical circuit connection with the receiv¬ 
ing station for the transmission of multiple contiguous packets. 
(The actual physical circuit over which individual packets are 
transmitted can vary during a session, but the logical circuit en¬ 
sures presentation of each packet to the receiving station in the 
proper order.) Information delivery is so rapid that the user ap¬ 
pears to have an end-to-end, dedicated channel. 

Users who do not support X.25 can access the public data 
network for packet data transmission; however, they cannot trans¬ 
mit directly to a DCE or network node. They must transmit to a 
special network-operated PAD, discussed earlier in this report. 
Terminal transmissions are stored in a buffer at the PAD. There 
they are assembled into packets and sent to the device at the other 
end of the virtual circuit. Packets arriving at the PAD from the 
network are reassembled into the appropriate format before they 
are sent on to the terminal. The PAD is programmed and config¬ 
ured to interface properly with the protocol and physical charac¬ 
teristics of the user’s device. Data presented to the PAD is refor¬ 
matted into X.25 format and forwarded to the DCE. 

Recommendation X.25 is divided into those specifications re¬ 
quired for a device or network to comply and those that are op¬ 
tional. Approximately one-third are required; the remaining two- 
thirds of the specifications are optional. 

The excess throughput capacity inherent in the X.25 standard 
allows for future network growth and technological progress. For 
example, a single X.25 interface can theoretically handle 4,095 
virtual channels, packet sizes up to 2048 bytes each, and packet 
sequencing up to 128 packets per logical channel. Most network 
suppliers’ nodal processors are too small to handle this much 
traffic through a single interface. Therefore, in practice, the sup¬ 
port offered over each interface is limited to the current capacity 
of the network’s access node. 

Functional Layers 

Recommendation X.25 defines three functional layers: the Physi¬ 
cal Layer (Level 1), the Link Layer (Level 2), and the Packet 
Layer (Level 3). These are consistent with the first three layers of 
the ISO Reference Model for Open Systems Interconnection 
(OSI). (Although OSI labels its third layer the Network Layer, its 
function parallels that of the Packet Layer. Both provide the 
means to establish, maintain, and terminate connections.) 

Level 1: Physical Level—outlines the physical, functional, 
and electrical characteristics of the DTE/DCE interface. X.21 
uses the transmission of coded character strings across a 15-pin 
connector to define standard interface functions, e.g., Transmit 
Data. Its specifications are defined in TSS Recommendation 
X.21. 

Although X.21 is the recommended physical-level interface 
for X.25, the availability of data communications equipment with 
X.21 capabilities is limited, especially in the United States. As a 
result, the ITU-TSS has accepted an interim recommendation, 
X.21 bis, as the X.25 physical interface. X.21 bis is functionally 
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Frame Formats for Packet Mode Transmission 
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Control 
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Packet 24 

Control 1 ,024 

User Data 

16 

Field Sequence 
Check 

8 

Flag 


Description 


Value is 01111110. 

Value for DTE to DCE command frame is "10000000". 

Value for DTE to DCE response frame is "11000000". 

Value for DCE to DTE command frame is "11000000". 

Value for DCE to DTE response frame is "10000000". 

I Frame: 

Bit 1 is "0". 

Bits 2, 3, 4, are N(S) (transmitter send sequence count). 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receive sequence count). 

S Frame: 

Bit 1 is "1". 

Bit 2 is "0". 

Bits 3, 4 identify Supervisory Command. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receiver sequence count). 

U Frame: 

Bit 1 is 1. 

Bit 2 is 1. 

Bits 3, 4 are first part of Unnumbered Frame Command identifier. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are second part of Unnumbered Frame Command identifier. 
Control information. 

1,024 data bits are normal maximum; exceptional maximum is 2,040 data bits. 
Check bits for user data. 


Value is "01111110". 


equivalent to EIARS-232-C, which assigns a separate function to 
each pin across a 25-pin connector. 

Level 2: Link Level—describes the link access procedures 
used for data interchange between a DCE and a DTE. In the TSS 
Recommendation X.21, International User Classes of Service in 
Public Data Networks , X.25 specifies that the DTE and DCE 
must operate in the following user classes of service: class 8 
(2400 bps), class 9 (4800 bps), class 10 (9600 bps), or class 11 
(48K bps). The procedure calls for a full-duplex facility so that 


the DTE and DCE can conduct two-way, simultaneous, indepen¬ 
dent transmissions. The procedures use the principles and termi¬ 
nology of the High-level Data Link Control (HDLC) protocol 
specified by the International Organization for Standardization. 

Level 2 comprises three procedures: the Link Access Proce¬ 
dure, the Link Access Procedure Balanced, and the Multilink Pro¬ 
cedure (MLP). The original X.25 data link control procedure em¬ 
braced LAP, which is similar to the HDLC Asynchronous 
Response Mode (ARM). Due to some incompatibilities with 
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Table 5. X.25 Level 2 Commands and Responses 


Commands (1) Responses Encoding of Control Field 


Format 





1 

2 

3 

4 

5 

6 

7 8 

Information 

1 

(information) 



0 

1— 


-N(S)-1 

P 

|_ 

—N(R)—| 

transfer 












Supervisory 

RR (3) 

(receive ready) 

RNR 

(receive not ready) 

1 

0 

0 

0 

P/F 


N(R) 


RNR (3) 

(receive not ready) 

RNR 

(receive not ready) 

1 

0 

1 

0 

P/F 


N(R) 


REJ (3) 

(reject) 

REJ 

(reject) 

1 

0 

0 

1 

P/F 


N(R) 

Unnumbered 

SARM 

(set asynchronous 

DM 

(disconnected 









(2,3) 

response mode) 

(2) 

mode) 

1 

1 

1 

1 

P/F 

0 

0 0 


SABM 

(set asynchronous 











(2) 

balanced mode) 



1 

1 

1 

1 

P 

1 

0 0 


DISC 

(disconnect) 



1 

1 

0 

0 

P 

0 

1 0 




UA 

(unnumbered 












acknowledgment) 

1 

1 

0 

0 

F 

1 

1 0 




CMDR 

(connand reject) 

1 

1 

1 

0 

F 

0 

0 1 




FRMR 

(frame reject) 









(1) The need for, and use of, additional commands and responses are for further study. 

(2) DTEs do not have to implement both SARM and SABM; furthermore, DM and SABM need to be used if SARM only is used. 

(3) RR, RNR, and REJ supervisory command frames are not used by the DCE when SARM is used (LAP). 


some elements of procedures, Level 2 of the X.25 Recommenda¬ 
tion was revised to incorporate LAPB. Similar to the Asynchro¬ 
nous Balanced Mode (ABM) of HDLC, it provides for a 
“balanced” configuration; that is, each side of the link consists of 
a combined primary/secondary station. The Multilink Procedure 
is used for data transmission on one or more single links. Each 
link conforms to the X.25-defined frame structure and to the ele¬ 
ments of procedure described in LAPB. 

Software in both DTE and DCE performs Level 2 processing. 
This software appends control information onto packets that are 
ready for transmission, maintains control of the transmissions, 


performs transmission error checking, and strips a successfully 
received frame down to a packet. The packet consists of packet 
control information and (optionally) user data; packets are dis¬ 
cussed in detail later in this report. 

HDLC specifies certain control fields that must be appended 
to both ends of a packet, resulting in a transmission format called 
a frame. Appended in front of a packet are a beginning Flag field, 
an Address field, and a Control field. Appended behind the packet 
are a Frame Check Sequence field and a closing Flag field. 

Figure 3 gives the size and description of each field. The re¬ 
ceiving device uses the two Flag fields to ascertain the beginning 


Table 6. Summary of Packets Exchanged Between Terminals During a Virtual Call 


Events 


Activity at Calling DTE Activity at Called DTE 


Call Initiation 

Call Request packet is sent 

Call Connected packet is received 

Incoming Call packet is received 

Call Accepted packet is sent 

Data Transfer 

Data packet sent 

Data packet received 

Ready Receive packet sent 


Ready Receive packet received 

Data packet B sent* 


Data packet A sent* 

Data packet B received* 

Data packet A received* 

Disconnect 

Clear Request packet sent 

Clear Confirmation packet received 

Clear Indication packet received 

Clear Confirmation packet sent 


*Two-way (full-duplex) transmission of data packets between terminal equipment 
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Figure 4. 

X.25 User and Network Software Relationships 
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and ending of a frame. A single Flag field can be used as the 
closing flag for one frame and the opening flag of the next frame. 
The Address field, under HDLC, is used to identify the station(s) 
for which the command is intended in command frames or to 
identify the station sending the response in response frames. 

The Control field identifies the type of frame and supplies 
control information pertinent to that type of frame. A frame can be 
either an Information Frame (I-Frame), a Supervisory Frame (S- 
Frame), or an Unnumbered Frame (U-Frame). See Table 5 for the 
encoding of this field. 

An Information Frame contains a user packet. The Control 
field of the I-Frame contains the N(S) transmitter Send Sequence 
Count, the N(R) transmitter Receive Sequence Count, and the 
Poll/Final (P/F) bit. N(S) is the sequence number of this frame 
sent from this transmitter to this receiver. N(R) is the sequence 
number of the next frame this transmitter expects to get from the 
receiver when the receiver becomes a transmitter. The Poll/Final 
bit indicates whether a transmission acknowledgment is required 
or when the final frame in a stream has been transmitted. 

The Supervisory Frame transmits one of three supervisory 
commands and cannot contain user data. The Control field of the 
S-Frame contains the command, the P/F bit, and an N(R). Table 6 
summarizes the commands and responses possible in the Control 
field. 

The Unnumbered Frame extends the number of link control 
functions, without incrementing the sequence counts at either the 
sending or receiving station. 

A U-Frame control field contains the Unnumbered command 
and the P/F bit. One of the U-Frame commands initializes the 
DTE/DCE network to the ARM of operation, which permits both 
DTE and DCE to initiate transmission to each other. 

The Frame Check Sequence (FCS) field contains a 16-bit 
check pattern created at framing time by generating check bits 
based upon the binary value of the data in the packet. The receiv¬ 
ing device performs the same calculation and compares its results 
with the value that the sending device had placed in the FCS field. 
If these values do not agree, the frame has a transmission error 
and is discarded. Discarding causes the receiving device to send 
an S-Frame with the Reject Recovery command. This S-Frame 
contains the frame numbered N(R), thus acknowledging receipt 


of all frames numbered N(R)-1 and below, and initiates retrans¬ 
mission of frames N(R) and above. 

In effect, Level 2 envelops the packet in control information 
and prescribes procedures that ensure a high degree of transmis¬ 
sion accuracy and detection of lost frames during transmission. 

Level 3: Packet Level—describes the packet format and con¬ 
trol procedures for the exchange of packets between the DTE and 
the DCE. In addition to the user data packet format, there are 
several formats for DTE/DCE administrative messages. 

The software for formatting packets and controlling packet 
exchange is the Level 3 software resident in both the DTE and the 
DCE. Figure 4 shows the relationship of Level 3 and Level 2 
software operating in the DTE and the DCE. In the DTE, a user 
application program normally presents the data to be transmitted 
to the operating system’s communications access method. The 
access method invokes Level 3 software to append the packet 
header information, then invokes Level 2 software to create the 
frame. Packet header formats are discussed below. 

Once the frame is created, it is ready for transmission. Upon 
receiving the frame, the receiving DCE invokes Level 2 software 
to perform error detection and sequence checking and to strip the 
accepted frame down to a packet. The packet is presented to 
Level 3 software for packet-level processing and to prepare the 
packet for transmission to the destination DCE. The physical ad¬ 
dress of the destination DTE, derived from the call initiation, is 
inserted into the packet during Level 3 processing. At the network 
destination DCE, Level 3 software reformats the packet control 
information and presents the resulting packet to Level 2 software; 
Level 2 software includes the packet in a frame for transmission 
to the destination DTE (user). At the destination DTE (user), 
Level 2 software performs error detection and sequence checking 
and strips accepted frames down to the packet. Level 3 software is 
then applied to the packet to strip the header information from the 
packet and pass the user information to the appropriate applica¬ 
tion program via the communications access method. Table 7 
summarizes the types of packets exchanged between terminals. 

The packet header consists of three octets. In Octet 1, the first 
four bits represent the Logical Channel Group Number, and the 
final four bits represent the General Format Identifier. Octet 2 
represents the Logical Channel Number, and Octet 3 represents 
the Packet Type Identifier. See Figure 5. 
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Table 7. Packet Types and Their Use in Various Functions 


Packet Type Service 


Function 

From DCE to DTE 

From DTE to DCE 

Switched 

Virtual 

Circuit 

Perm. 

Virtual 

Circuit 

Call Setup and Cleaning 

In Incoming Call 

Call Request 

X 



Call Connected 

Call Accepted 

X 



Clear Indication 

Clear Request 

X 



DCE Clear 

DTE Clear 




Confirmation 

Confirmation 

X 


Data and Interrupt 

DCE Data 

DTE Data 

X 

X 


DCE Interrupt 

DTE Interrupt 

X 

X 


DCE Interrupt 

DTE Interrupt 




Confirmation 

Confirmation 

X 

X 

Flow Control and Reset 

DCE RR (Receive 

DTE RR 

X 

X 


Ready) 

DTE RNR 

X 

X 


DCE RNR (Receive 

DTE REJ* 

X 

X 


Not Ready) 

Reset Request 

X 

X 


Reset Indication 

DTE Reset 




DCE Reset 

Confirmation 

X 

X 


Confirmation 




Restart 

Restart Indication 

Restart Request 

X 

X 


DCE Restart 

DTE Restart 




Confirmation 

Confirmation 

X 

X 

Diagnostics 

Diagnostics 


X 

X 


The Logical Channel Group Number and the Logical Channel 
Number provide the routing information that directs the packet 
over one of the logical channels. The numbering system for the 
logical channels is dynamic and refers to a switched data path 
within the packet network. 

The General Format Identifier indicates the general format of 
the rest of the header. Specific bit patterns are established for the 
following: Call Setup packets; Clearing, Flow Control, Interrupt, 
Reset, Restart, and Diagnostic packets; and Data packets. 

The Packet Type Identifier establishes the packet’s function. 
Examples of functions include call setup, priorities, and data. If 
applicable, it may identify the packet’s place in sequence. See 
Table 7 for the various packet types. 

Packet-Level Procedures 

X.25 Level 3 defines procedures for call initiation, data transfer, 
interrupts, reset, restart, and clearing. Some of these procedures 
are summarized below. 

Call Initiation: The Level 3 software in a DTE initiates a 
transmission by sending a Call Request packet. This packet en¬ 
ables the calling DTE to request the opening of a logical channel. 
The calling DTE designates the channel number based upon the 
original assignments that were made when the user subscribed to 
the network. The Call Request packet also informs the network of 
the calling DTE’s address and of the called DTE’s address. Until 
the call is disconnected, the network retains the addresses of both 
devices associated with the logical channel number. Therefore, 
each Data packet that is transmitted needs to contain only the 
logical channel number. The network appends the destination ad¬ 
dress just before routing the packet. At the time the Call Request 
is issued, the logical channel indicated by the calling DTE must 
be in a Ready state, that is, not being used to handle another call. 
Upon receipt of the Call Request by the called DTE, the specified 
logical channel is designated as being in the DTE Waiting state. 
The packet is then transmitted to the destination DCE. 
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The destination DCE transmits an Incoming Call packet to the 
originating DTE and places the logical channel in the DCE Wait¬ 
ing state. 

The called DTE indicates its willingness to accept the call by 
transmitting a Call Accepted packet across the DTE/DCE inter¬ 
face. The Call Accepted packet specifies the same logical channel 
that is indicated by the Incoming Call packet. This places the 
specified logical channel in the Data Transfer state. (The logical 
channel at the calling DCE is still in the Wait state.) 

A Call Connected packet is then sent by the DCE to the calling 
DTE and sets the logical channel status to the Data Transfer state; 
the logical channel is then ready for transfer of Data packets. This 
applies only for virtual circuit connections; for permanent virtual 
circuit connections, the assigned logical channels are always in 
the Data Transfer state. 

It is possible for a DCE to receive a Call Request (from a 
DTE) and an Incoming Call (from the network) simultaneously, 
with both messages specifying the same logical channel. This is 
called a call collision; when a collision occurs, the DCE cancels 
the Incoming Call and proceeds to process the Call Request. 

Data Transfer: Once the logical channel is in the Data Trans¬ 
fer state, Data, Flow Control, or Reset Information packets can be 
transmitted. 

The Data packet format includes the packet send and receive 
sequence numbers. The calling DTE can transmit up to a prede¬ 
termined number of packets before requiring a response. This 
number is referred to as the window. All packet networks must 
accommodate a lower window edge of at least eight, permitting at 
least seven packets to be outstanding before an acknowledgment 
is required. The upper window value (the maximum number of 
outstanding packets) may not exceed 127 (modulo 128). 

Upon receipt of an authorized packet, the receiving device can 
either authorize additional transmission by transmitting a Receive 
Ready packet to the sending device or deny authorization to trans¬ 
mit by issuing a Receive Not Ready packet. 

When transmitting Data packets, the Interrupt packet can by¬ 
pass flow control (authorization procedures). A DTE can transmit 
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Figure 5. 

XJ25 Packet Header Format 
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an Interrupt packet to another DTE. To avoid swamping the re¬ 
ceiver with Interrupt packets, the sender cannot send a second 
Interrupt packet until the first Interrupt packet is acknowledged 
by an Interrupt Confirmation packet. 

While Data packets or Interrupt packets are being transmitted, 
issuing a Reset Request packet can reset the call. A DCE initiates 
a reset by issuing a Reset Indication packet. In either case, the 
logical channel is placed in the Data Transfer state. Any Data, 
Interrupt, Receive Ready (RR), or Receive Not Ready (RNR) 
packets in the network at the time of reset are ignored. If a DTE 
and DCE transmit Reset packets simultaneously, a reset collision 
occurs. The net effect is to place the logical channel in the Data 
Transfer state, ready for Data and Interrupt packets. 

A DTE or a DCE initiates a request for clearing (disconnect¬ 
ing) a logical channel. Upon confirmation by the other device, the 
logical channel is placed in the Ready state. 

Error Handling (Packet Level): When an error occurs, the 
DCE transmits Reset, Clear, and Restart indication packets to the 
DTE. Reset reinitializes a virtual call or permanent virtual circuit. 
Reset removes all Data and Interrupt packets on the logical chan¬ 
nel and resets the lower window edge to zero. It affects only one 
logical channel number (one user). Reset procedures, which ap¬ 
ply only in the Data Transfer state, handle specific error events, 
such as local procedure error, remote procedure error, network 
congestion, incompatible destination, network out of order, etc. 
Clear affects only one logical channel number (one user). It clears 
a session when, for example, the host or host link crashes. In this 
case, the network initiates Clear procedures on the terminal link. 
It effectively logs off the terminal user. Clear resets the lower 
window edge to 0. Restart affects all users (all logical channels on 
a given link) and clears all calls on that link. Restart is used when 
a failed link returns to service; it makes sure that all calls were 
cleared when the link went down. Restart also is used when either 
side (DTE or DCE) reports error conditions at the packet level; 
the good side initiates the restart procedures. 

In some networks, a Diagnostic packet indicates unusual error 
conditions. A Diagnostic packet from the DCE provides informa¬ 
tion on events that are considered unrecoverable at the packet 
level; the information permits the DTE to analyze and initiate 
recovery by higher levels. No confirmation is required on receipt 
of a Diagnostic packet. 


Implementation Considerations for Users 

X.25 recognizes that DTEs differ in their degree of sophistication. 
A simple DTE may have fixed packet formats and built-in param¬ 
eter values, while a sophisticated DTE may work with varying 
packet formats and provide variable parameters to take advantage 
of the many network functions and signaling capabilities offered. 

At the physical level, the transmission rate DTE uses to access 
an X.25 network should be governed by the throughput and re¬ 
sponse time requirements of the user. Factors to consider include 
the maximum number of virtual circuits operating simultaneously 
and traffic characteristics of throughput-critical and response¬ 
time-critical virtual circuits. 

At the link level, LAPs and LAPBs are defined. A DTE might 
implement only LAPB. Parameters that are part of the LAPB 
procedures can be set to constants for all network connections. 
For example, a timer (Tl) may be set according to the slowest 
required line speed; a constant such as three seconds may be used. 
Also, the maximum permitted number of unacknowledged 
I-Frames (information frames) may be determined. The network 
provider must agree to this. All networks support a window of at 
least seven I-Frames. The maximum packet size (number of bits) 
of the I-Frame must also be established. 

If the DTE handles certain character sizes (octets), the frame 
level should be capable of accommodating any number of bits 
correctly (generate acknowledgment, calculate frame check se¬ 
quence). How such a properly received frame is processed de¬ 
pends on the individual system and may include actions such as 
discarding the frame, padding it, clearing the call, or resetting. 


Connections Between Packet 
Switched Data Networks 

TSS Recommendation X.75 describes the procedures for the in¬ 
terconnection of packet switched networks. Many public packet 
switched data networks support X.75 procedures, including 
AT&T Accunet, TransCanada’s Datapac, Graphnet Freedom Net¬ 
work II, US Sprint’s SprintNet, and WangPac networks. 

X.75 is similar to X.25 in that it specifies procedures for the 
physical, link, and packet levels. Signal Terminal Equipment 
(STE), which acts as a bridge node between networks, imple¬ 
ments X.75 procedures. A related standard, TSS X.121, defines 
the international numbering plan for public data networks. 
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Recommendation X.75 

Recommendation X.75, Terminal and Transmit Call Control Pro¬ 
cedures and Data Transfer System on International Circuits Be¬ 
tween Packet-Switched Data Networks , provides the rules for 
transmitting data between different data networks. The basic sys¬ 
tem structure is made up of communicating elements that func¬ 
tion independently. These elements include the physical circuits, 
which comprise links A1 or G1 (as defined in X.92), and a set of 
mechanical, electrical, functional, and procedural interface char¬ 
acteristics; packet transfer procedures, which operate over the 
physical circuits and provide for the transport of packets between 
STEs; and packet signaling procedures, which use the packet data 
transfer procedures and provide for the exchange of call control 
information and user traffic between STEs. 

Figure 6 shows the basic system structure of the signaling and 
data transfer procedures. The international link is assumed to be 
data link A1 and/or data link G1 as defined in Recommendation 
X.92. The international link should be capable of supporting full- 
duplex operation. 

Link-level packet transfer procedures between STEs consist 
of the Single Link Procedure (SLP) and the Multilink Procedure 
(MLP). The SLP is used for data interchange over a single physi¬ 
cal circuit between two STEs. When multiple physical circuits are 
used in parallel, the SLP is used independently on each circuit. 
The MLP is used for data interchange over multiple parallel links. 
The MLP may be used over a single link when the communicat¬ 
ing parties agree to this procedure. Transmissions are full duplex. 
SLP is based upon the LAPB as described in X.25 and uses the 
principle and terminology of the International Organization for 
Standardization’s (ISO’s) HDLC. For SLP, either modulo 8 (non- 
extended mode) or the modulo 128 (extended mode) may be 
used. The MLP is based on the multilink procedures specified by 
the ISO and performs the functions of distributing packets across 
available SLPs. 

Three channel states are defined: the link channel state, which 
provides transmission in one direction; the active channel state, 
which means that the incoming or outgoing channel is receiving 
or transmitting a frame; and the idle channel state, which means 
that the incoming or outgoing channel is receiving or transmitting 
at least 15 contiguous 1 bits. 

Data is transmitted in frames. Each frame must contain an 
Opening Rag (8 bits), an Address field (8 bits), a Control field (8 
bits), a FCS field (16 bits), and a Closing Rag (8 bits). An Infor¬ 
mation field of an unspecified number of bits, which follows the 
Control field, is optional. 


The Control field contains a command or response, and se¬ 
quence numbers if applicable. Control field formats may be one 
of three types: numbered information transfer (I format), num¬ 
bered supervisory functions (S format), and unnumbered control 
functions (U format). The I format performs information transfer 
functions. The S format performs link supervisory control func¬ 
tions, such as acknowledging I frames, requesting transmission of 
I frames, and requesting a temporary suspension of transmission 
of I frames. The U format provides additional link control func¬ 
tions. 

Each I frame is numbered sequentially. The send state variable 
V(S) represents the sequence number of the next in-sequence I 
frame to be transmitted. The value of the V(S) is incremented by 
one with each successive I frame transmission but cannot exceed 
N(R) of the last received I or S format frame by more than the 
maximum number of outstanding frames. The send sequence 
number N(S), contained only in I frames, is set equal to the value 
of V(S). The receive state variable V(R) represents the sequence 
number of the next in-sequence I frame expected to be received. 
The value of V(R) is incremented by one when an error-free, 
in-sequence I frame whose N(S) equals V(R) is received. Both I 
frames and S frames contain the receive sequence number N(R). 
N(R) is the expected send sequence number of the next received I 
frame. When the STE transmits N(R), it indicates that all I frames 
numbered up to and including N(R)-1 have been received cor¬ 
rectly. 

All frames contain the Poll/Final (P/F) bit, which is referred to 
as the P bit in command frames and the F bit in response frames. 
The STE solicits a response from another STE by setting the P bit 
to 1; the answering STE responds by setting the F bit to 1. The 
following commands and responses are supported: 

• Information (I) command—transfers sequentially numbered 
frames that contain an information field; 

• Receive ready (RR) command and response—used by the 
STE to indicate that it is ready to receive an I frame or to 
acknowledge a previously received I frame; 

• Receive not ready (RNR) command and response—used by 
the STE to indicate a busy condition; 

• Reject (REJ) command and response—used by the STE to 
request retransmission of I frames beginning with frame num¬ 
bered N(R); 

• Set asynchronous balanced mode (SABM) command—an 
unnumbered command used to set the addressed STE in the 


Figure 6. 

Basic System Structure of X.75 Signaling and Data Transfer Procedures 
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asynchronous balanced mode information transfer phase; all 
command/response control fields are one octet (eight bits); 

• Set asynchronous balanced mode extended (SABME) com¬ 
mand—an unnumbered command used to set the addressed 
STE in the asynchronous balanced mode information transfer 
phase; all numbered command/response control fields are two 
octets; all unnumbered command/response control fields are 
one octet; 

• Disconnect (DISC) command—terminates the previously set 
mode; DISC indicates that the STE transmitting DISC is sus¬ 
pending operation; 

• Unnumbered acknowledge (UA) response—used by the STE 
to acknowledge mode-setting commands; 

• Disconnected mode (DM) response—reports STE status 
when it is logically disconnected from the link and is in the 
disconnected phase; and 

• Frame reject (FRMR) response—indicates an error condition 
that is not recoverable by retransmission of the frame. 

Packet-level signaling procedures relate to the transfer of packets 
at the STE-X/STE-Y (X/Y) interface. Recommendation X.75 
specifies signaling procedures for virtual call setup and clearing, 
for permanent virtual circuit service, for data and interrupt trans¬ 
fer, for flow control, and for reset. 

Logical channels are used to complete simultaneous virtual 
calls and/or permanent virtual circuits. A logical channel group 
number and a logical channel number (in the range 0 to 15 inclu¬ 
sive and 0 to 255 inclusive, respectively) are assigned to each 
virtual call and permanent virtual circuit. The logical channel 
group number and the logical channel number are contained in 
each packet type, except restart packets. 

The procedures for virtual call setup and clearing are used 
only when a logical channel is in the packet-level ready (RL) 
state. If call setup is possible, and no call or call attempt exists, the 
logical channel is in the ready (PL) state (within the RL state). 
Call setup is initiated when the STE sends a Call Request packet 
across the X/Y interface. The Call Request packet specifies a 
logical channel in the PL state. The logical channel is then placed 
in the call request state. The called STE indicates acceptance by 
the called DTE by sending a Call Connected packet across the 
X/Y interface. It specifies the same logical channel as that re¬ 
quested by the Call Request packet. The logical channel is then 
placed in the flow control ready (DL) state within the data trans¬ 
fer (P4) state. 

A logical channel (in any state) can be cleared when the STE 
sends a Clear Request packet, which specifies the logical chan¬ 
nel, across the X/Y interface. Upon receipt of a Clear Request 
packet, STE-X or STE-Y frees the logical channel and transmits a 
Clear Confirmation packet that specifies the same channel. This 
places the logical channel in the ready state within the RL state. 
Permanent virtual circuits require no call setup or clearing. 

Data transfer procedures apply independently to each logical 
channel at the X/Y interface. In the data transfer (P4) state, Data, 
Interrupt , Flow Control , and Reset packets may be sent and re¬ 
ceived by the STE. The data transfer state exists within the 
packet-level ready state of a logical channel. Each Data packet 
contains a sequence number called the packet send sequence 
number P(S); only Data packets contain the P(S). 

The procedures for flow control and reset apply only in the 
data transfer state. Flow control applies to Data packets. A win¬ 
dow is defined for each direction of transmission at the X/Y in¬ 
terface. The lowest number in the window is called the lower 
window edge. The maximum window edge does not exceed 
modulo 8 or 128, is unique to each logical channel, and is re¬ 
served for a period of time. For a particular call, two window 
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sizes, one for each direction of transmission, may be selected. The 
packet receive sequence number P(R) (modulo 8 or 128) conveys 
information from the receiver for the transmission of data pack¬ 
ets. The P(R) becomes the lower window edge when transmitted 
across the X/Y interface, thereby authorizing additional data 
packets to cross the X/Y interface. 

Reset procedures are used to reinitialize a single call and apply 
only in the data transfer state. The STE sends a Reset Request 
packet that specifies the logical channel to indicate a request for 
reset. The logical channel is placed in the reset request state. The 
requested STE confirms by sending a Reset Confirmation packet, 
which places the logical channel in the flow control ready state. 

Restart procedures are used to clear all calls simultaneously. 
When the STE sends a Restart Request packet, the X/Y interface 
for each logical channel is placed in the restart request state. In 
this state all packets, except Restart Request and Restart Confir¬ 
mation packets, are discarded by the X/Y interface. An STE con¬ 
firms by sending a Restart Confirmation packet, which places all 
channels in the ready state. 

Packet formats are based on the general structure of packets as 
defined in X.25. 


Trends in Packet Switching 

X.25 packet switching is widely supported in existing data pro¬ 
cessing and data communications equipment. All major host 
computer and communications processor vendors, for example, 
have incorporated X.25 interfaces into their products. This is part 
of an overall trend in accepting international standards and the 
increasing availability of products conforming to these standards. 

The ITU-TSS published revisions to the X Series standards in 
1984 and in 1989. Since that time, the ratification and publication 
of revisions has become a continuous, ongoing process. Since the 
major building blocks for X.25 were laid by 1984, all subsequent 
changes have been, and will continue to be, relatively minor. 
Some recent changes have revolved around efforts to make TSS 
X Series standards compatible with those of the International Or¬ 
ganization for Standardization. Currently, discussions on how to 
provide greater interoperability between various X.25 networks 
and between X.25 and frame-relay networks is taking place. Ma¬ 
jor developments in packet switching today, however, center not 
around X.25, but around the development of new ISDN-related 
technologies, such as frame relay and Broadband ISDN, which 
provide much higher throughput through simplified packetization 
and routing schemes. This section discusses post-1984 changes to 
X.25 and its relationship to ISDN. 

Major Changes in 1988 Revisions 

In the 1988 revised standards, there were no changes at the physi¬ 
cal and link levels. At the packet level, however, a new facility for 
redirecting calls, Call Deflection , was established. In 1984 the 
ITU-TSS had made available a new Call Redirection facility, al¬ 
lowing the network to redirect all calls destined for a given ad¬ 
dress. This redirection could occur when the destination was out 
of order or busy, or it could be based on time of day or other 
criteria. The 1988 facility extended this capability, allowing the 
destination subscriber to clear incoming calls to another party on 
a call-selective basis. The Clear Request packet contains the Call 
Deflection information that profiles the desired alternate party. 

Relationship Between ITU-TSS and ISO Efforts 
TSS X.25 packet-level protocol specifies a virtual circuit service; 
the ISO has issued a compatible version of the packet standard, 
ISO 8208. In recent years, ITU-TSS and ISO organizations have 
worked on standards to carry longer addresses in the DTE field to 
facilitate interworking with ISDN (E.164). 
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In 1988 the ITU-TSS also modified the Address Extension 
facilities to be consistent with ISO address length. Previously, a 
provisional 32-decimal/16-octet field had been recommended; 
this address length was increased to 40 decimals/20 octets. The 
ISO also added these address recommendations to Addendum 2 
of ISO 8348 (Connection-Mode Network Service); the ITU-TSS 
adoption is X.213. 

Connectionless Issues: Relationships With ISO Efforts 

At any layer of the OSI Reference Model, two basic forms of 
operation are possible: connection oriented and connectionless. 
Connection-oriented service involves a connection establishment 
phase, a data transfer phase, and a connection termination phase. 
A logical connection is set up between end entities prior to ex¬ 
changing data. In a connectionless service, typical of local area 
networks, each packet is independently routed to the destination. 
No connection establishment activities are required since each 
data unit is independent of the previous or subsequent one. 

Each transmission mode has a niche where it represents the 
best approach. For example, file transfers may benefit from a 
connection-oriented service, while point-of-sale inquiries may be 
best served by a connectionless service. 

Traditionally, the ITU-TSS has pursued a connection-oriented 
philosophy, while ISO has addressed both connection and con¬ 
nectionless services. The original OSI standard, ISO 7498, is con¬ 
nection oriented. ISO provided connectionless service, however, 
by issuing an addendum to that protocol: ISO 7498/DAD 1. ISO 
has issued a standard for connection-mode network service (ISO 
8348), while the ITU-TSS has issued an identical service, X.213. 
In regard to X.25 itself, however, ISO has decided not to pursue 
the connectionless service, formerly known as “datagram” ser¬ 
vice. 

Packet Switching in ISDN 

The goal of the Integrated Services Digital Network (ISDN) is to 
provide an end-to-end digital path over a set of standardized user 
interfaces, giving the user the capability to signal the network 
through an out-of-band channel. (In contrast, in X.25, the user 
signals the network in-band by issuing packets such as Call Re¬ 
quest, Call Accepted, etc.) 

Currently, different types of interfaces to the telephone net¬ 
work exist for different services. These interfaces include two- 
wire switched, two-wire dedicated, four-wire dedicated, and 
DDS. ISDN provides a small set of interfaces that can be used for 
multiple applications. The ITU-TSS has defined the following 
interfaces for ISDN: 

• 2B+D—two 64K bps channels and a 16K bps packet/signaling 
channel (also called the Basic Rate Interface). 

• 23B+D—twenty-three 64K bps channels and a 64K bps 
packet/signaling channel (also called the Primary Rate Inter¬ 
face). 

• 3H0+D—three 384K bps channels and one 64K bps packet/ 
signaling channel. 

• Hll—nonchannelized 1.536Mbps. 

• HI 2—nonchannelized 1.920Mbps. 

• Multislotted—multiples of 64K bps channels (up to 1.536M 
bps) under the customer’s control. 

• Broadband—high data rates, based on an approach called syn¬ 
chronous optical network (Sonet), building on multiples of 
51.84M bps. Sonet standards negotiations began in 1986. The 
ITU-TSS approved phase I of the standards in 1988 and phase 
II in 1989. This architecture has been called Broadband ISDN, 
in contrast to the other interfaces that have been considered part 
of Narrowband ISDN. 


With the exception of Broadband ISDN, all of the above inter¬ 
faces can be carried on unloaded copper loops. Using fiber has 
also been considered, as it would make the local loop more ro¬ 
bust. Out-of-band signaling makes possible a new class of ser¬ 
vices. In addition, the 16K bps D-channel connects directly to the 
BOC’s packet switched network, providing the subscriber with 
the data multiplexing advantages packet switching offers. 

ITU-TSS ISDN Standards 

ISDN provides a specific protocol that users can employ to signal 
the network. Currently, a three-layer protocol suite is defined. At 
the Basic Rate, the Physical Layer manages a 192K bps, full- 
duplex bitstream using time-compression techniques and time- 
division methods to recover the two B-channels and one D-chan¬ 
nel. The remaining 48K bps stream is used for Physical Layer 
control information. The defined standards are 1.420 (Basic Rate 
Interface Definition), 1.430 (Basic Rate Interface Layer 1), 1.421 
(Primary Rate Interface Definition), and 1.431 (Primary Rate In¬ 
terface Layer 1). 

The Data Link Layer is not defined for transparent B-channels 
used for circuit switched voice or data, but it is defined for the 
D-channel. For Narrowband ISDN, the D-channel employs a 
LAP-D Link Layer protocol, which is a subset of the ISO HDLC 
Data Link protocol, as specified in TSS Recommendations Q.920 
(1.440) and X.921 (1.441). It provides statistical multiplexing for 
three channel types: signaling information for managing the B- 
channels; packet switched service over the D-channel; and op¬ 
tional channels, used for telemetry of other applications. 

The Network Layer protocol for the signaling channel is 
specified in TSS Q.930 (1.450) and Q.931 (1.451) specifications. 
It provides the mechanism for establishing and terminating con¬ 
nections on the B-channels and other network control functions. 
For the packet switched service over the D-channel, the Network 
Layer protocol is X.25. 

A technique is required for specifying whether user-to-net- 
work signaling, user packet data, or user telemetry data is being 
sent over the D-channel. This technique involves the use of a 
service access point identifier (SAPI). 

Each layer in the OSI Reference Model communicates with 
the layers above and below it across an interface. The interface is 
through one or more service access points (SAPs). SAPs have a 
number of uses, including subaddressing for internetworking 
situations, Transport Layer applications, and for user data packet 
service over an ISDN D-channel. 

Considering the applications to the Transport Layer, one 
should note that two general types of addressing in a communica¬ 
tions architecture are available. Each host on the network is as¬ 
signed a network address, allowing the network to deliver data to 
the proper computer. Each process within a host, moreover, is 
given an address that is unique within the host itself, allowing the 
Transport Layer to deliver data to the proper process. These pro¬ 
cess addresses are identified using SAPs. A similar approach is 
followed for ISDN. 

LAP-D must deal with two levels of multiplexing. First, at a 
subscriber location, multiple-user devices may be sharing the 
same physical interface. Second, each user device may support 
multiple types of traffic, including packet switched data and sig¬ 
naling. To accomplish this type of multiplexing, LAP-D employs 
a two-part address consisting of a terminal endpoint identifier 
(TEI) and a SAPI. Typically, each user terminal is given a distin¬ 
guishing TEI. The SAPI identifies the traffic type and the Data 
Link Layer services directed to Layer 3. For example, the SAPI 
value of 0 directs the frames to Layer 3 for call-control proce¬ 
dures; a SAPI value of 16 indicates a packet communication pro¬ 
cedure. See Figure 7. 
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Figure 7. 

SAP 1 Action far a Basic Rate D-Channel 


Signaling Packet Telemetry 



Frame Relay 

Frame relay is a rapidly emerging, standards-based addressing 
technique that has great potential in LAN/WAN networking and 
other interactive applications requiring high-throughput, low-de¬ 
lay transmission. Frame relay is based on the TSS Layer 2 proto¬ 
col developed for ISDN, Link Access Protocol D (LAPD). Unlike 
conventional X.25 packet switching, frame relay uses variable 
packet lengths and performs error checking only at the remote 
end of transmission. Any errors occurring between intermediate 
network nodes are assumed caught and corrected by higher-layer 
protocols. Thus, intermediate nodes simply forward packets 
(called frames) without processing the datastream. In addition, 
frames must be received in the order in which they were sent, 
unlike some X.25 networks, which involves considerably less 
machine processing at the opposite end of transmission. These 
efficiencies result in superior performance, with data rates up to 
or above Tl/El levels. 

Vendors from several different networking disciplines have 
established themselves as frame-relay equipment providers. 
These include traditional packet switched equipment suppliers 
such as Northern Telecom, Alcatel Data Networks, BBN Systems 
and Technologies, BT North America, and Hughes Network Sys¬ 
tems; T-carrier nodal processor vendors such as Ascom Timeplex, 
General DataComm, Newbridge Networks, Network Equipment 
Technologies, and StrataCom; and LAN internetworking (bridge 
and router) vendors. 

Most commercial frame-relay products are based on some or 
all of the following American National Standards Institute 
(ANSI) specifications: 
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• T1.602: Data Link Layer Signaling Specification for Applica¬ 
tions at the User-Network Interface 

• T1.606: Frame Relaying Bearer Service—Architectural 
Framework and Service Description (T1S1/88-225) 

• T1S1.2: Addendum to T 1.606 (Frame Relaying Bearer Ser¬ 
vice—Architectural Framework and Service Description) on 
Congestion Management Principles 

• T1.617: Signaling Specification for Frame Relay Bearer Ser¬ 
vice 

• T1.618: Core Aspects of Frame Protocol for use with Frame 
Relay Bearer Service 

The ITU-TSS has released frame-relay specification 7.722, en¬ 
titled “Framework for Providing Additional Packet Mode Bearer 
Services.” TSS 1.462 (X.31), “Support of Packet Mode Terminal 
Equipment by an ISDN,” describes a packet mode service. 

Broadband ISDN and Cell Relay 

Broadband ISDN (BISDN) is the blueprint for public networks in 
the mid-1990s (1994 and beyond). It is being developed to sup¬ 
port switched (on demand), semipermanent, and permanent 
broadband connections for both point-to-point and point-to-mul- 
tipoint applications. Channels operating at 155M bps and 622M 
bps will be available under BISDN, allowing transmission of 
data, video, and digitized voice. Broadband services are aimed at 
both business applications and residential subscribers. Connec¬ 
tions will support both circuit mode and packet mode services of 
a single media, mixed-media, and multimedia. 
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BISDN’s foundation is Asynchronous Transfer Mode (ATM), 
a high-bandwidth, low-delay switching and multiplexing technol¬ 
ogy in which information is packetized into fixed-size slots called 
cells. A cell consists of an information field that is transported 
transparently by the network and a header containing routing in¬ 
formation. With simplified protocols and cells with a fixed, short 
length (53 bytes), ATM makes very high data rates possible. 

The ITU-TSS has issued several Broadband ISDN specifica¬ 
tions in its I-Series recommendations. 1.361 , the BISDN ATM 
Layer Specification, defines the ATM cell structure and coding, 
including header formats and coding at both the User-Network 
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Interface (UNI) and Network Node Interface (NNI). It also de¬ 
fines ATM protocol procedures. 1.311, entitled BISDN General 
Network Aspects , describes networking techniques, signaling 
principles, traffic control, and resource management for BISDN. 
It defines ATM virtual section, virtual path, and virtual channel 
concepts. 

Several off-the-shelf ATM products were released in late 1993 
by vendors of packet and frame-relay switches, T Carrier multi¬ 
plexers, and LAN routers vendors. Many more end-user ATM 
products, along with ATM public carrier services, will gradually 
become available in 1994 and 1995. ■ 
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